前情提要

昨天我們提出了一個疑問，測試code要怎麼證明寫的是好的?
又或者，我們要怎麼知道測試的code寫得已經滿足需求了?

案例

假設現在要測試一個function，這function會回傳兩個輸入加起來，我們要怎麼知道測試寫的是夠的呢?

function add(a:int,b:int)=
    a+b

遇到這樣的function，我們要寫幾個測試才夠?

我們可能會寫

• 正數相加: 確保function可以處理正數的狀況

Assertions.assertEquals(5, add(2, 3))

• 負數相加: 確保function可以處理負數的狀況

Assertions.assertEquals(-1, add(-2, 1))

• 零相加: 確保function可以處理0的狀況

Assertions.assertEquals(3, add(3, 0))

• 邊界條件: 確保function可以遇到邊界值會正常運作

Assertions.assertEquals(Int.MAX_VALUE, add(Int.MAX_VALUE, 0))

這樣就有4個測試了，但這些都是必要的嗎?
這時候可以透過幾種方法來檢查我們的測試是否足夠。

Coverage Rate

測試覆蓋率，如果我們的測試執行了function，它就會計算覆蓋率，如果覆蓋率越高，代表我們的測試至少有跑過大部分的程式碼，但覆蓋率高不代表有好的測試，因為我們也可以寫一堆function，然後沒有Assert來造假XD 這樣覆蓋率好高好高，但code說不訂是一坨大泥球!

Code Reveiw

自己經驗不足，不知道這樣夠不夠，很簡單，找夥伴一起來看，兩人的力量一定比一個強吧XD 可以找大老來幫忙一起看code，這樣就可以寫出比較好的測試了。

測試案例設計

透過設計具有不同的輸入以及邊界條件、異常狀況等來設計測試，這樣就可以確保我們的測試滿足很多條件，並且也能透過測試來加強我們code不足的地方! 比如說我們的add function就沒有考慮到邊界的情況! 這時候就可以來彌補囉XD

總結

我們可以透過撰寫很棒的測試，讓我們的程式可靠性上升，讓我們假日可以開心出遊玩~ 也讓我們可以持續整合持續部屬。

補充

除了functional requirement，程式設計師真正的價值其實是處理non-functional requirement，functional requirement本來就該達到，不然怎麼領薪水呢(X，但non-functional requirement通常就很考驗我們的技術，可靠性、速度、安全性等等。